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FOREWORD 



This report was prepared by the Value Engineering Staff at System 
Development Corporation (SDC), 2500 Colorado Avenue, Santa Monica, California, 
under contract with the 416M/P/418L Air Weapons Surveillance and Control SPO, 
Electronic Systems Division, L. 6. Hanscom Field, Bedford, Mass. It describes 
the Value Engineering effort on the BUIC III contract for the period 
1 July 1967 to 30 November 1967. 

The author is indebted to M.E. McCormick, who ably assisted in the 
implementation of the VE Plan, and in addition, provided a technical review 
of this report. 

This Technical Report has been reviewed and is approved. 
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L. C. Allard, Colonel USAF 

System Program Director 
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ABSTRACT 

This document contains a report on the application of Value Engineering/ 
Value Analysis techniques to the BUIC III contract, which is basically a 
software (computer programming) contract. It describes the procedures used, 
the problems encountered, and recommendations for VE on future software contracts, 
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I. INTRODUCTION 

Within the last twenty years computer programming has mushroomed into 
a multi-million dollar industry. As with most hastily developed industries, 
this phenomenal growth has been accompanied by a great amount of technical 
enthusiasm and a corresponding lack of control and standardization. As 
experience is gained in program production, it is apparent that many of the 
business management techniques, with appropriate modifications, are applicable 
to program production. One of these management techniques, Value Engineering, 
has been a part of government hardware contracts for some time. 

The BUIC III contract, dated 1 October 1966, received by SDC was a Cost Plus 
Fixed Fee (CPFF) contract and was in excess of $1,000,000. Pursuant to Armed 
Services Procurement Regulation (ASPR) 1-17, a Value Engineering Program 
Requirement clause was levied upon the Contractor. Prior to receipt of this 
contract, the Contractor: (1) had not previously been involved with any 
Value Engineering (VE) requirement, and (2) the application of Value 
Engineering techniques to the Contractor's prime area of interest—computer 
program development and production—was open to question. With these two 
potential problem areas in mind, the Contractor proceeded to generate a 
Value Engineering Plan which described his outline for an in-house training 
and education program, for selection of high-cost contract areas for analysis, 
and for Value Analysis procedures. 

To our knowledge the BUIC III contract was the first computer program contract 
in which the ASPR Value Engineering program clause was applied. This interim 
Technical Report contains the contractor's VE plan as applied to the contract, 
the initial results of the implementation of the VE plan, the problems 
encountered, and recommendations for future actions. 

II. DEFINITION OF TERMS 

A. Value Engineering 

"ASPR 1-17, Revision 23, dated 1 June 1967, defines Value Engineer- 
ing as "a systematic and creative effort, not required by any other provision 
of the contract, directed toward analyzing each contract item or task to 
ensure that its essential function is provided at the lowest overall cost." 

B. Value Analysis 

Value Analysis is the assessment of the value of a product, process, 
or procedure, including close scrutiny and definition of its functions and 
comparative costs of performing those functions in other reasonable ways. 



C. Value Assurance 

Value Assurance results from the application of Value Engineering 
techniques during the initial creative phases of a functional process. Value 
Assurance efforts are intended to assure a high value product or process before, 
rather than after, production begins. It parallels the purpose and meaning 
of other similar phases such as reliability assurance and quality assurance. 

D. Software 

As used in this report, software encompasses those procedures, 
documents, and activities required for the development, design, production, 
testing, and updating of a computer program system, including the training 
procedures required to operate the system. 
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III. IMPLEMENTATION OF THE VALUE ENGINEERING PLAN 

The proposed Value Engineering Plan received approval in May 1967. 
Contract coverage, however, did not begin until 1 July 1967. The plan out- 
lined the main VE functions to be performed. 

A. Training 

Since the contractor's prior exposure to Value Engineering was 
minimal, a basic 10-hour seminar was provided for some 60 selected super- 
visory and technical personnel. References 2, 3, 4, and 7, and 14 in 
Appendix B provided the base for the seminar. The 10-hour seminar consisted 
of five 2-hour sessions. The outline for the sessions is contained in 
Appendix A. 

B. Organization 

An attempt was made to employ Value Engineers who had a background 
in software production. None were available and two VE personnel were chosen 
from in-house. Each had a minimum of ten years experience in program or 
training materials production, and both had previous experience in cost- 
effectiveness and quality assurance work. In the belief that morale holds up 
better and that there is a resulting better chance of getting Value Engineer- 
ing changes accepted in-house if the individuals actually performing the job 
participate in the Value Analysis, SDC chose the staff approach method of 
organization. After investigation of areas where savings were deemed 
possible, study teams were organized, with representation from system design, 
program design, programming, and Value Engineering areas. 

Depending upon the functional area being investigated, the study team was 
headed by the most cognizant member of the team, with the Value Engineering 
member either heading the study or simply participating in it. 

C. Value Analysis 

As mentioned previously, funding for the Value Engineering effort 
did not begin until 1 July 1967. This late start limited the effectiveness 
of the proposed Value Engineering Plan. To achieve optimum results, Value 
Engineering personnel must participate in the generation of the contract 
proposal, and a detailed Value Engineering Plan, complete with goals and 
costings, should be a part of the proposal. It is most important that 
immediately after contract negotiations, the Statement of Work be thoroughly 
analyzed by Value Engineering personnel for high-cost areas and for assign- 
ment of VE teams for functional analysis. Predicted or potential savings 
should not be made until this initial analysis. 



Since it was not possible to follow this schedule for BUIC III, the VE effort 
was at a distinct disadvantage in attempting to analyze the technical 
functional areas, because program requirements and design were set in concrete 
and any changes to them were apt to place the contract schedule in jeopardy. 
In at least one area of analysis, a potential savings was deemed possible; 
but upon further investigation, it was discovered that the items in question 
were already produced using the old method, and there was to be no further 
production under the terms of the contract! 

D. Selection of Value Engineering Tasks 

For VE purposes, the computer program production process can be 
divided into three areas for analysis: 

. The means of inputting data to a computer. 
. The processing of data by the computer (the computer program). 
. The outputting of the description and use of the program system 
(documents). 

Realizing that pure programming system functions are too far downstream for 
Value Analysis, the Value Engineering effort concentrated on the analysis of 
computer inputs and outputs. Several VE studies were undertaken with the 
following results. 

1. Use of optical scanner as an input device . The present method 
of using punched cards to initially input data to a computer was analyzed. 
Optical scanning of specially typewritten materials was studied for potential 
cost savings. The study indicated that available scanners do not lend them- 
selves to present SDC input requirements. As further industry advances are 
made, scanners should be examined again for application to BUIC III inputs. 

2. Standardization of input manuscr ipts. Presently a variety of 
colorcoded and columnated manuscripts are used to input data. A study is 
currently underway to determine if a standard coding manuscript of 80 columns 
can be used. Specially made plastic overlays will be used to specify columnar 
tradings. The present average cost of manuscripts is $ .04 each. Anticipated 
cost of a standard manuscript is $ .01. 

3. Use of a program to produce documents . An automatic means of 
producing and updating program documentation (Text 90) was analyzed. A VECP 
for using Text 90 for each of the three BUIC III CEIs was submitted to the SP0 
for consideration. It is significant to note that had these three VECPs been 
proposed and approved in the early stages of the contract, savings on the 
order of $70-80,000 would have resulted instead of the $9,000 as estimated in 
the VECPs. The importance of performing the Value Analysis as early in the 
contract as possible cannot be overemphasized. These VECPs were disapproved 
by the SP0 because the contractor did not provide for turnover and updating 

of the Text 90 program as part of the VECP. 



4. Elimination of unnecessary training tapes . Elimination of cross- 
tell simulation tapes for training purposes was examined. Although it was 
found that the tapes could be replaced by cards at a savings, there was 
insufficient remaining production to amortize implementation costs. 

5. Use of microfiche in lieu of hard copy documents . The use of 
microfiche copy is currently being examined. Initial page costs of $ .40 for 
hard copy vs $ .05 for fiche and reproduction costs of $ .0125 for hard copy 
vs $.003 for fiche make the potential savings realizable. It is anticipated 
that significant savings, both in the BUIC III and future contracts, will 
occur by the substitution of microfiche for a hard copy document. All users 
of the microfiche will be provided a reader, and all personnel will have 
access to a reader-printer, if a hard copy reproduction is necessary. 

Because of time constraints, it was not possible for VE personnel to analyze 
the BUIC III program system prior to its production. Program system functions 
can and should be analyzed by trained VE personnel. The functions of a 
computer-based air defense command/control system generally include the 
following: 

1. Executive control. 

2. Environment definition. 

3. Identification. 

4. Sensor data processing. 

5. Console switch interpretation. 

6. Manual data insertion. 

7. Digital and situation displays. 

8. Weapons control and assignment. 

9. Weapons guidance. 

10. Data link input and output. 

11. Communication message make up. 

12. Height information processing. 

13. Telling information to adjacent and higher commands. 

14. Recording of vital data. 

15. Simulation for exercising purposes. 

16. Restart capability. 

The Value Engineer should examine each one of those functions, asking the 
following questions. 

1. Are common program subroutines written only once and accessible 
by all computer program components (CPCs)? 

2. Is the data base made up compactly and for ease of later 
updating? 

3. Do functions, subfunctions, or subroutines presently exist in 
another program system, which can be used with little or no 
modification? 

4. Are CPCs broken into the best possible elements? Can some be 
combined? Are they operated in the least time-consuming sequence? 



5. Are table lookups or direct conversion routines the best means 
of performing a function? 

6. Can any of the CPCs be coded using a higher-order language? Is 
it worthwhile to do this for certain CPCs and/or refine them 
manually? 

7. Are the number of interfaces between CPCs and CEIs at a minimum? 

8. Does the Contract Data Requirements List contain unnecessary 
data items? Can the quantities of data items be reduced? 

9. Are all test procedures necessary? Can tests for standard 
program routines, that have previously undergone testing, be 
deleted or reduced in scope? 

10. In a multiple-site system, are installation teams required at 
each facility, or can a test team be located at a central 
source to provide service to all sites? 

11. If training materials (simulation tapes, exercise maps, lists, 
scripts, cards, etc.) are a CDRL requirement, can they be 
reduced in number or can acceptable substitutes be provided? 
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IV. PROBLEMS 

In addition to the usual roadblocks encountered in attempting to apply 
VE to software, others, perhaps unique to the software industry, came up 
during the implementation of the VE Plan. Some of these can be overcome 
through training and by writing enough programs for all the available computers, 
so that programming primarily becomes a task of putting together already 
programmed functions. As the roadblocks were uncovered by the VE staff, 
discussions were held with the technical personnel to overcome the blockages. 
A short description of each roadblock, with the VE response, follows. 

A. Programming as a Unique Effort 

Because of the unique requirements (mission, equipment, personnel 
of the BUIC III command/control system), programming is to a large degree a 
one of a kind effort. Except for the general logic involved, programs cannot 
be simply taken off the shelf and put together to meet the software require- 
ments. 

VE Response 

Any task function, even a unique one, can be laid out in a VE job plan. When- 
ever the details and related costs of a task function are laid open for 
analysis, it is a rare occasion when the analysis does not lead to lesser 
costs. In instances where costs are not reduced, close scrutiny of each 
program component can result in increased performance and/or reduced operating 
size. 

B. Lack of Repetitive Production Costs 

In any hardware contract where multiple assemblies are specified, 
a relatively small VE savings per assembly can result in substantial overall 
savings. For example, in a contract calling for 5,000 identical assemblies, 
a savings of only $10 per assembly results in a total of $50,000 saved. The 
$10 savings per unit can probably be realized without any disruption to the 
work force, since the savings in materials requires a change in the type or 
quantities purchased and, in manpower, a reduction in production time which 
can be used to produce the same or other items for another customer. In 
short, it is not necessary to have large individual VE changes in hardware 
projects to produce cost reductions. This does not hold, however, in the 
production of computer programs. In command/control systems such as BUIC III, 
an overwhelming proportion of contract dollars is used in the production of 
the initial computer program. Even though 40 to 50 copies of the master tape 
containing the computer program may be required, the cost of reproducing these 
tapes is minute compared to the original production costs. 



VE Response 

Because of this unusual proportion of production costs, VE analyses to be 
worthwhile must result in significant savings per single application. SDC 
estimated this figure to be a minimum of $5,000; this estimate was used to 
take care of any error and delay in the implementation of a change. Again, 
a VE job plan is effective in bringing to light potential cost savings. While 
it is true that some of the savings may be small because of the one-of-a-kind 
production nature of software, they can result in a substantial savings if 
lumped together and used to reduce overall contract costs. 

C. Ratio of Production Costs 

The relation between the dollars spent on contract wages and 
salaries and those spent on materials also presents an unusual proportion. In 
SDC Proposal 355(D) on the BUIC III contract, an overwhelming proportion 
(93.6%) of the cost was for direct salaries, burden (supervisory staff, fringe 
benefits, administrative overhead), travel, and field allowances. Any large 
VE savings must come out of this wage and salary pot. Since the assets and 
productive talents of any software organization are represented by a reservoir 
of professional skills, any really large and significant VE change will probably 
result in a disruption of these people either by reorganization or termination. 
There is not usually a "backlog of orders" to fill the void created by such 
an event. Contracts are let with specific start and end dates and must be 
staffed as called for in the contract. Unless a contractor is engaged in many 
contracts at the same time, it is impossible to smooth out the production 
peaks and valleys. 

VE Response 

While this problem creates a challenge for any management, it can be overcome 
by a change in management organization, planning, and costing techniques. 
For future contracts, SDC has organized software capability pools such as 
specification writing, programming, and testing. With this kind of organization 
several contract tasks may be processed in parallel. By further dividing 
functional tasks, more than one contract can be serviced by the same individual 
"simultaneously." For example, rather than providing a single cost charge 
number for a large task function such as the production of the Air Defense 
Program CEI, this large task can be broken down into smaller task functions 
such as Part I Specification production, Part II Specification production, etc. 
Each of these subtasks can further be broken down into subsubtasks such as 
data gathering, data coordination, draft specification publication, draft 
specification review, and final specification publication. Costs and schedules 
are assigned and evaluated for each subsubtask. A master schedule of tasks 
is monitored, with personnel assigned on a task, rather than a contract basis. 



D. Lack of Detailed Costs 

Although the term "production" is used in the computer program 
development process, the production process is more in the nature of a service, 
for each program system represents a specific solution to a specific require- 
ment. If in large contracts it is reasonable to assume that some functional 
areas are overcosted and overspecified, is it not reasonable to assume that 
some functional areas have been undercosted and underspecified? While the 
contractor gets to share in the savings of an approved VECP, who gets to share 
in the losses that he may sustain because of underestimating costs? 

VE Response 

Breaking down task functions into subtasks and subsubtasks will permit a more 
accurate assessment of costs, in both proposal and contract performance. If 
programs or program functions can be eliminated without degrading the Air 
Defense mission, they should be the subject of a VE study team. 

E. Lack of Contract Details 

By its very nature a command/control computer program contract cannot 
be specific; the numbers and kinds of programs; the numbers and kinds of data 
tables, etc., are the tasks to be provided under the terms of the contract. 
Although the BUIC III Statement of Work did specify the gross program systems 
to be provided—the Air Defense Computer Program, the System Exercise Computer 
Program, and the Utility Computer Program—it did not specify further details 
concerning the construction of these program systems. To qualify as a VECP, a 
change must save money and require a change to the contract. By definition 
then, changes to programming techniques, methods, tables, registers, etc., 
would not qualify as VECPs. 

VE Response 

Although Value Engineering Change Proposals may be limited because of the 
definition of a Value Engineering Change, the Contractor can reduce the total 
contract costs through Value Analysis techniques. 
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V. SUMMARY AND RECOMMENDATIONS 

In spite of the unique roadblocks described previously, software is 
amenable to the techniques of Value Engineering. Because of the non-repeti- 
tiveness and the one-of-a-kind nature of software, VECPs, as currently defined, 
must necessarily result in large individual savings. High dollar VECPs are 
therefore unlikely, particularly during the acquisition phase of the software 
system; however, application of VE techniques early in the system life cycle 
can result in intangible savings through improved performance and efficiency, 
or even of assuring contract performance. These savings, though intangible, 
can well be worth any measurable dollar savings. For example, a frequent cause 
of complaint by a program system user is that the system does not perform accord- 
ing to specifications. Program systems are so interleaved and interwoven 
that the later this is discovered, the more difficult and more costly it is to 
remedy. By having VE personnel participate in the program design phase, the 
probability of this occurring is lessened. 

The greatest VE savings can occur in the preproposal period. A well-trained, 
conscientious VE staff can best perform at that time, because technical details 
are not frozen and line personnel are not as adamant about change as they are 
after the contract is received. It is paradoxical that the opportunity for the 
greatest savings exists BEFORE the contractor qualifies for sharing under the 
terms of any VE contract clause. On large competitive procurements, the 
definition phase of the system procurement provides the necessary time to 
perform the Value Analysis. On sole source Cost Plus Fixed Fee (CPFF) 
procurements, this activity is best done during the preproposal activities or 
immediately after the contract is received. 

The necessity of valid cost data cannot be overemphasized. While cost data is 
available for repetitive operations such as the inputting of data to a computer 
or the outputting of data as a document, they are not available for system 
design, or program design, or program coding, except in the form of gross 
historical data. Cost data for these latter subfunctions need to be carefully 
developed. If computer program VECPs are to be produced during the system 
acquisition phase, some means must be developed to assign a dollar value to 
the savings accrued from a reduction in computer register space or reduction 
in program operating time. 

The following additional points on VE are recommended for further software 
procurement: 

A. Initial Use of VE 

For software companies who have had no Value Engineering program 
in existence, a minimum of three months should be allowed to set up a 
program. Reasonable costs for this are allowable under paraqraph 1-1705.3 of 
ASPR. 

10 



B. A Program Index as a VE Tool 

As with any task, tools make the task easier. Within the past 
fifteen years, the Air Force has spent millions of dollars on software. In 
many cases it has paid for the same programming function more than once, 
because both the Air Force and the contractor were unaware that the function 
had previously been programmed. The author was unable to determine if an index 
or catalog exists of all Air Force-purchased computer programs, computer 
program systems, and computer program subroutines. Such an index of all 
program functions, detailing the function, the language used, the computer 
used, etc., would be of immense value to a software Value Engineer. Programming 
of mathematical functions, for example, could easily be off-the-shelf programming, 

C. Early Application of VE Techniques 

The dollar advantage of applying VE techniques as early as 
possible in the contract cannot be overstated. With contracts lacking a 
definition phase, Value Analysis is best accomplished in the preproposal , and 
Statement of Work preparations. While this is advantageous in hardware 
procurement, it is doubly necessary in software procurement. With few 
exceptions, true software VE changes are not practical after the SOW has been 
published. A true software change is one requiring a change to the computer 
program requirements and a concomitant change to the contract or Part I or 
Part II Specifications. 

D. Cost Tree 

As early as possible a functional cost tree should be prepared 
as shown in Figure 1. A similar chart could be devised for any software 
contract. In the example shown, the three BUIC CEIs have been divided into 
several subfunctions. The chart is not meant to be complete and is only 
shown as a guide for laying out functional costs. Using the predetermined 
cost of each CEI, Value Engineering personnel should perform a detailed cost 
analysis for each major function. Those functions which appear to have 
potential cost savings should be assigned a target cost reduction figure. 
This figure should be lower than the contract-estimated cost and should be 
established as the least cost required to perform the function. Monitoring 
points must be set up so that predicted cost expenditures can be compared with 
actuals and decisions made accordingly. Some functions, such as installation, 
do not lend themselves to a new target cost. 

E. Participation of VE Personnel at Test and Design Reviews 

It is mandatory that VE personnel participate in the various 
reviews and tests that occur during the acquisition phase of a system. This 
includes the System Design Review (SDR), Preliminary Design Review (PDR), 
Critical Design Review (CDR), First Article Configuration Inspection (FACI), 
Preliminary Qualification Test (PQT), and Final Qualification Test (FQT). 
Their influence can be felt most during the System Design Review and declines 
as the program proceeds through its acquisition cycle. 
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APPENDIX A 
First 2-Hour Session 



1. Definition and history of value engineering and a list of 
applicable references. 

2. Types of value engineering contract clauses, and responsibilities 
under each clause. 

3. Percentage of total contract cost to be spent on value engineering, 

4. Kinds of returns expected from a value engineering program. 

5. Roadblocks encountered in moutning a value engineering effort. 

Second 2-Hour Session 

1. Organization and responsibilities of a value engineering office. 

2. Approach to value analyses. 

3. Application of value engineering to computer program. 

4. Necessity of obtaining accurate costs for value engineering. 

5. Selection of computer program functions for value analysis. 

Third 2-Hour Session 
1. How to cost a VECP for computer programs. 

Fourth 2-Hour Session 

1. How to initiate and process a VECP. 

2. The importance of schedules in a VECP. 

Fifth 2-Hour Session 

1. Possible pitfalls and problems in value engineering. 

2. Reporting on value engineering. 

3. Assessing the effectivity of a value engineering program. 
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APPENDIX B 

VALUE ENGINEERING REFERENCES 

1. MIL-V-38352 dated 13 May 1964. 

2. Armed Services Procurement Regulation (ASPR) 1-17, dated 1 June 1967. 

3. Value Analysis/Value Engineering, by the AMA. 

4. Techniques of Value Analysis and Engineering, by L. D. Miles. 

5. AFR 70-16 Value Engineering, dated 12 December 1963. 

6. AD 614 612, The Management of a Value Engineering Program in Defense 
Contracts, April 1964. 

7. H 111, Value Engineering Handbook, 29 March 1963. 

8. AD 600 394, Value Engineering, October 1964. 

9. AD 482 096, Value Engineering Conference, February 1964. 

10. AD 618 070, In-House Value Engineering, June 1965. 

11. AD 609 520, Value Analysis, March 1963. 

12. AD 609 883, Instruction Notes for Case Problems in the Contractual Aspects 
of Value Engineering, April 1964. 

13. AD 624 810, The Application of Defense Value Engineering, January 1966. 

14. AD 604 663, Principles and Applications of Value Engineering, 1964. 

15. AD 625 659, Value Responsibilities of the Designer, December 1965. 

16. AD 605 454, Fringe Effects of Value Engineering, May 1964. 

17. ASDP 70-1, Procurement Guide to Value Engineering, March 1963. 

18. ESD TR-66-282, Advantageous Definitions Concerning Value, April 1966. 

19. ORDP 40-2, Value Analysis, August 1961. 

20. TM-3225/000/01 , Management Handbook for the Estimation of Computer Program 
Costs, System Development Corporation, 20 March 1967. 
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